Various embodiments relate generally to communication technologies, and in particular, to a technology for a non-IP Multimedia Subsystem (IMS) user to access an IMS network.
The Public Land Mobile Network (PLMN) defined by the 3rd Generation Partnership Project (3GPP) can be logically divided into two parts: a Core Network (CN) and an Access Network (AN). The CN can be subdivided into a Circuit Switched (CS) domain, a Packet Switched (PS) domain, and an IP Multimedia Subsystem (IMS).
In the CS domain, the Mobile Switching Center (MSC) handles several mobility and routing dependant functions for CS-based services. The main CS-based service is a voice call.
In the PS domain, a Serving GPRS Support Node (SGSN) handles several mobility and routing dependant functions needed for PS-based services. The SGSN is connected to a Gateway GPRS Support Node (GGSN), which is configured to offer access to the IMS. A network is conventionally organized so that the MSC, GGSN, and SGSN are connected to the HLR (Home Location Register). The HLR stores all subscriber specific data.
In the CS-Domain, the control of connections (e.g., reserving data transfer means) and calls (e.g., calling, negotiation of codecs, hang-up) are both done on the MSC. For example, after a successful establishment of a call, the MSC routes the voice data towards the network.
In the PS-domain, there is a division of duties between the control of connections (e.g., reserving network layer addresses or IP-addresses and means for PS-data transfer), otherwise known as “sessions” and the control of application layer services (e.g., voice calls with voice codec, data rate, required QoS). The SGSN controls sessions in addition to routing voice-data after successful establishment of a session. The IMS controls application layer services. For example, the IMS defines means to request and negotiate services and their parameters on an application layer between a UE and the connection endpoint. The IMS also relies on the core-network to setup and maintain the appropriate sessions via transferring the associated data through the network to the UE.
One feature of a conventional network, is the ability to update a position status of a UE (User Equipment) that has changed locations. In a conventional network, a UE in Idle Mode performs cell-selection autonomously and thus the network is not aware which cell the UE is currently located. The network is only aware of the Location Area (LA) which is in general an area spanned by a number of mobile radio cells. In case of network triggered connection setup is required the network pages the UE in all mobile radio cells of the LA that the UE is currently registered in. Each mobile radio cell indicates the LA where it belongs to by transmitting a Location Area Identity (LAI).
A conventional location update procedure for the CS domain user is shown in FIG. 1. More specifically, FIG. 1 shows a location update procedure that includes changing both the LA and MSC. Although the relation between MSCs and LA is a choice of the network operator, the location update procedure of FIG. 1 includes changing both the LA and MSC for a clear presentation of the location areas update procedure.
Prior to UE 102 moving from the cell of NodeB 106 to the cell of NodeB 116, UE 102 is registered at the LA of the cell of NodeB 106 and RNC 107 and obtained a TMSI from MSC 108. UE 102 has also stored the Location Area Identity (LAI) broadcasted by NodeB 106. At Step 1, UE 102, in idle mode, moves to the cell of NodeB 116. NodeB 116 transmits a different LAI than NodeB 106. Thus, a location update is initiated.
That is, when UE 102 moves from the cell of NodeB 106 to the cell of NodeB 116, UE 102 reads a LAI from the system information transmitted by NodeB 116. Because the LAI transmitted by NodeB 116 is different from the LAI received from NodeB 106 and stored in UE 102, UE 102 initiates a location update at Step 2 by transmitting a location updating request message towards NodeB 116 and Radio Network Controller (RNC) 120 of MSC 122. The location updating request message includes the Temporary Mobile Subscriber Identity (TMSI) assigned by NodeB 106 and the LAI of NodeB 106. An acknowledge message, which indicates the successful establishment of the radio resource connection, is transmitted back to UE 102 at 118.
The now “new” MSC 122 detects that the received LAI is different from its own LAI. At Step 3, MSC 122 thus uses the LAI received from UE 102 to obtain the address of MSC 108 and transmits a send parameters message to the MSC 108. A send parameters message also includes the TMSI sent to MSC 122 by UE 102. MSC 108 responds by sending the International Mobile Subscriber Identity (IMSI) that corresponds to the received TMSI user identity back to MSC 122.
At Step 4, MSC 122 sends an Update Location message to HLR 128. The Update Location message includes the IMSI of UE 102 and the address of MSC 122. HLR 128 updates the record for UE 102 with the received parameters and sends an Insert Subscriber Data message back to MSC 122. The message includes security credentials for UE 102. MSC 122 creates a record for UE 102 and transmits an Insert Subscriber Data Result message to HLR 128 to indicate the successful creation of the data record in MSC 122.
At Step 5, HLR 128 transmits a Cancel Location message to MSC 108. MSC 108 deletes the record associated with UE 102 and transmits a Cancel Location Result message back to HLR 128. HLR 128 transmits to MSC 122 an Update Location Result message indicating a successful location update in HLR 128.
At step 6, MSC 122 initiates the authenticating process for UE 102 by transmitting to UE 102 an authentication request message, which includes a security challenge. UE 102 verifies, based on the authentication request message, that the request is trustful and computes a result to the challenge. UE 102 then transmits the result back to MSC 122. MSC 122 compares the result with the stored data earlier obtained from HLR 128. If the result matches, UE 102 is authenticated.
At Step 7, MSC 122 initiates ciphering for the connection towards UE 102 by transmitting a Ciphering Mode Command message to RNC 120, which forwards the message to UE 102. UE 102 switches to cipher mode and transmits a Ciphering Mode Complete message to RNC 120, which forwards the message to MSC 122.
At Step 8, MSC 122 assigns a TMSI to UE 102 and transmits the TMSI with the message Location Updating Accept to UE 102. UE 102 starts using this TMSI and transmits the TMSI Reallocation Complete message back to MSC 122. This indicates the successful completion of the location updating procedure.
After successful completion of the location update procedure, the network is aware of the new location area of UE 102, MSC 122 has obtained required subscriber data, and UE 102 has obtained a new temporary ID, a TMSI.
The above procedure shown in FIG. 1 only allows UE 102 to use CS-domain network resources of a Core Network. Using conventional techniques, UE 102 must initiate a GPRS attach procedure in order to obtain services from the PS-domain.
A conventional GPRS attach procedure and associated message exchanges are illustrated in FIG. 2.
At Step 1, UE 102 is either switched on or is otherwise not attached to the PS-Domain. At Step 2, UE 102 transmits an Attach Request message towards NodeB 114. The message is forwarded to RNC 120 and SGSN 122 and includes the RAI and the currently assigned P-TMSI or if a P-TMSI is not available, an IMSI.
At Step 3a, SGSN 122 transmits an Identification Request message to SGSN 108 by using the RAI previously received by UE 102. The message also includes in the P-TIMSI. SGSN 108 responds by sending a identification response message back to SGSN 122. The message includes the IMSI and security credentials.
At Step 3b, SGSN 122 sends a Send Authentication Info message, which includes the IMSI, to HLR 128. HLR 128 sends a Send Authentication Info ACK message, which includes the security credentials, back to SGSN 122. SGSN 122 initiates the authentication procedure for UE 102 by transmitting to UE 102 an Authentication and Ciphering Request message, which includes a security challenge. UE 102 verifies, based on the authentication request message, that the request is trustful and computes a result to the challenge. UE 102 then transmits the result back to SGSN 122 with an Authentication and Ciphering Response message. SGSN 122 compares the result computed by UE 102 with the stored data obtained from HLR 128, and if the result matches, UE 102 is authenticated.
At Step 4, SGSN 122 transmits an Update Location message, which includes the IMSI and new RAI, to HLR 128. HLR 128 updates the record for UE 102 with the received parameters and sends an Update Location ACK message back to SGSN 122.
At Step 5, SGSN 122 assigns a TMSI to UE 102 and transmits the message Attach Accept with the TMSI to UE 102. UE 102 utilizes the received TMSI and transmits an Attach Complete message back to SGSN 122. The message indicates the successful completion of the GPRS attach procedure.
The procedures of FIG. 1 and FIG. 2 only allow UE 102 to use CS domain and PS domain network resources of a Core Network. In order to use IMS-based services, UE 102 has to register in the IMS. Several requirements are defined for UEs to be able to register in the IMS, one of which is the presence of an IMS Subscriber Identity Module (ISIM). In the early phases of implementing IMS, it is expected that many UEs cannot fulfill these requirements, including UEs that do not have or cannot support an ISIM. To enable access to IMS by non-IMS compliant UEs, the GPRS-IMS Bundled Authentication (GIBA) procedure is defined. The procedure can be used by UEs which are using the PS domain to access the IMS.
A conventional GPRS-IMS Bundled Authentication procedure and message exchanges are illustrated in FIG. 3.
Four network elements are relevant in the IMS:
Proxy Call Session Control Function (P-CSCF) 130 is the first contact point within the IMS and behaves like a Proxy, i.e. it accepts requests and services them internally or forwards them on.
Interrogating CSCF (I-CSCF) 132 is the contact point within an operator's network for all connections destined to a user of that network Operator, or a roaming user currently located within that network operator's service area.
Serving CSCF (S-CSCF) 134 performs the session control services for a UE. S-CSCF 134 maintains a session state as needed by the network operator for support of services.
The Home Subscriber Server (HSS) 136 is a subscriber database similar to an HLR, but with enhanced authentication, authorization, and accounting functionality.
At Step 1, UE 102 transmits an Activate PDPD Context Request message to SGSN 122 via NodeB 114 and RNC 120. The message establishes a communication link between GGSN 138 and UE 102. UE 102 then transmits a Create PDPD Context Request message to GGSN 138. A PDP address (e.g., an IP Address) is assigned by SGSN 122, GGSN 138, or by an external Packet Data Network. An Accounting Request Start Request message, which includes an assigned PDP address, MSISDN, and IMSI, is then transmitted to the HSS 136. HSS 136 stores the relation between the transmitted data and transmits an Accounting Request Start Answer message to GGSN 138, which also stores the relation between the data. GGSN 138 then transmits a Create PDP Context Response message to SGSN 122. SGSN 122 transmits an Activate PDPD Context Accept message, which includes the assigned PDP address, to UE 102.
At Step 2, UE 102 transmits an SIP Register message, which includes the assigned PDP address and the IMS Public User Identity (IMPU), to GGSN 138. GGSN 138 checks whether the PDP address is correct (e.g. it is not spoofed). If the PDPD address is correct, GGSN 138 forwards the message to P-CSCF 130. P-CSCF 130 checks the source IP address against the SIP “via” field, and if both are the same, P-CSCF 130 forwards the message to I-CSCF 132. I-CSCF 132 transmits a User Authentication Request message, which includes the IMPU, to HSS 136. HSS 136 acknowledges the authentication to I-CSCF 132 with the message User Authentication Answer.
At Step 3, I-CSCF 132 sends the SIP Register message to S-CSCF 134. This triggers S-CSCF 134 to transmit to HSS 136 the message Multimedia-Auth-Request, which includes the IMPU and an indication that GIBA is being used. HSS 136 maps IMPU to the IMSI or MSISDN of UE 102 and reads the stored IP address for UE 102. HSS 136 then transmits a Multimedia-Auth-Answer message, which includes the stored IP-Address, back to S-CSCF 134. S-CSCF 134 checks the received IP-Address with the IP-Address received from I-CSCF 132. If the received IP-Addresses are the same, S-CSCF 134 transmits a Server-Assignment-Request message to HSS 136. HSS 136 stores the received data and transmits a Server-Assignment-Answer back to S-CSCF 134.
At Step 4, S-CSCF 134 completes the GPRS-IMS Bundled Authentication procedure by transmitting an SIP 200 OK message back to UE 102.
The GPRS-IMS Bundled Authentication procedure shown in FIG. 3 requires integrating the data of a HLR into the HSS so that the HSS can register a legacy UE with a USIM and thus use the resources of the IMS. Such an approach requires replacing the conventional HLRs or overlying one or more special HSSes for providing IMS services on the conventional networks while the conventional HLRs remain unchanged to provide the CS and PS domain services.
Solutions under discussion by the Third Generation Partnership Project (3GPP) include using a Home Node B (HNB) and Home Node B-Gateway (HNB-GW) for access to the PS-Domain and IMS for voice services and require a connection between the HNB Subsystem and an MSC. This is unfavorable as the HNB Subsystem and MSC connection requires the operator providing additional signaling and network resources.
In addition, such a solution requires deriving the IMS subscription needed for IMS registration from the UE address used in the 3G core network, such as IMSI derived IMPU. In implementing the IMSI derived IMPU, the network element responsible for IMS registration generates the IMPU by using the IMSI of the relating UE (e.g. 2483235551234@323.248.imsi.3gppnetwork.org). Thus, HLRs or HSSes need to be configured to accept the IMS Registration from all UEs that have a valid IMSI. This requires the HLR/HSS to generate and maintain large numbers of related subscriber records.
Other solutions include an IMS client in the HNB. This requires storing the IMSI of the UE in the HNB in order to perform IMS registration. It is preferred, though, to keep the IMSI protected and therefore not to transmit it un-ciphered over the air to an HNB or store it in an un-secure location such as an HNB.